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Digital Equipment'Corporation - Software Specification 


PREFACE 


This is a Software Product Specification. It is the definitiv 
description in measurable terms of the goals, capabilities, and exterr.a 
characteristics of the KA630 console program. It is the commitment c 
WHAT IS TO BE BUILT as agreed by the Product Team. 

No changes are to be made to the product as described here, unles 
approved and documented as an amendment to this Specification. 

Associated Documents: 

1. The KA630 Processor Specification which describes the processc 
board of which this software product (in ROM) is a component. 

2. The KA630 System Development Plan, which describes ri. 
development project to design, build, test, evaluate, an 
deliver this product. 

3. The KA630 ROM Diagnostic Specification which describes the RC 
based diagnostics which are part of this program. 

4. DEC Standard 32, the VAX Architecture Standard, which i 
includes the definition of the VAX console system (13-Sep-82 - 
Rev 3). 

5. The VIDEO SYSTEM STANDARDS Reference Manual which defines th 
video terminal architecture for DEC terminals. 

6. DEC Standard 138, "Registry of Control Functions for Characre 
Imaging Devices". 


Change History: 

Date: 25-July-1983 

Revision 1.0 Original KA630 phase zero version. 


Date: 22-February-l984 

Revision 1.15 Revisions for phase 1 

VMB details and figures defined according to "MicroVAX 
CPU Technical Description", second draft, October 1983 
This revision brings the specification up to phase 
status. All subsequent revisions will be tracked b 
change bars in the left margin. 


Revisions for phase 1 - continued 

Spelling corrections, deleted vestigial text fragment 
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Revision 1.16 
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remaining from previous versions, a correction to 
discussion of national replacement characters was ma 
powerup mode was simplified, QVSS location wa 
described, boot flag bits 0 and 7 were dropped. 


Revision 1.17 Revisions for phase 1 - continued 

Power-up modes redefined, section on diagnostic 
enlarged, number of console languages enlarged from 5 r 
10, documentation of all TOY registers strictly interr.a 
to the console program was removed, console flag bio 
moved to CPMBX TOY register, CPFLG TOY regisrs 
eliminated, power-up figures revised. 


Revision 1.18 Revisions for phase 1 - continued 

Revision of appendix a, LED and console output codes 
halt message texts converted to abbreviation so as c 
avoid requirements for translation. 

Date: 22-Jun-1984 

Revision 1.19 Revisions for delayed phase 1 - continued 

Discussion of the power-up sequence and the overal 
organization of the beginning of the Softwar 
Capabilities section was revised. Wording around ais 
boot was modified. 

Cleanup for a pre-phase-1 release. 


Date: 18-Jul-1984 

Revision 1.20 Converted processor name from KDQ32 to KA630, adae 

Portuguese to the list of supported languages. 


Date: 2-Aug-1984 

Revision 1.21 Changed spec name from KA630 to KA630-A. Delere 

vestigial documentation of "interrupt page" base 
console memory. 


Date: 10-Sept-84 

Revision 2.0 Text of user-friendly console messages revised an 

reduced. Post Phase 1 copy. 
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Date: 2-Nov-84 

Revision 2.1 Rearrange test sequence, add QxSS information, 

screen displays. 

Date: 31 January 1985 

Revision 2.2 Correct PROM boot definition. Correct language 

alg. displays. 
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PRODUCT SUMM-f 


1 PRODUCT SUMMARY 

This document describes the KA630 console program. This program 
conjunction with KA630 hardware implements the KA630 console sys.^ 
which gains control whenever KA630 "halts". For the KA630, "haltir., 
means only that control is transferred to this program, not that c. 
processor stops executing instructions. 

When the console program is running, it provides services expected of 
VAX-11 console system. In particular, the following services a: 
available: 

o Automatic restart or bootstrap following processor halts c 
initial power-up. 

o An interactive command language allowing the user to exarr.i: 
and alter the state of the processor. 

o Diagnostic tests executed on power up that check out the CPU 
the memory system and the Q22-bus map. 

o Support of video or hardcopy terminals as the console terming 
as well as support of QVSS or QDSS based bitmapped terminals. 


2 ENVIRONMENT 
2.1 Users 

Engineering, Manufacturing, Field Service and customers will use thi 
program to test, configure and boot their system. This program i 
needed by these users both to provide an easy means to bootstrap a KA.62 
system and to detect and isolate system malfunctions. 

Of these users, all but customers are assumed to be compute 
"sophisticates". While this will often be true of customers as well, r. 
such assumption is made. Target customers include both sophisticate 
users who can use and understand all the features provided by th 
console program as well as unsophisticated users who know next t 
nothing about computers. 

Users a.re not assumed to speak English. The console program may c 
directed to output all console messages in either English, French 
German, Spanish, Italian, Norwegian, Dutch, Swedish, Finish, Danish c 
Portuguese. If when the system powers up there is no languac 
specified, it prompts the user for the language to use. The use 
language is recorded in battery backed up RAM so the preferred languac 
is retained when the system is shut off. 
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2.2 Hardware 

The console program is located in ROM on the KA630 processor board. T1 
ROM address range is located in the KA630's local I/O space. Tr 
program uses the KA630 processor LEDs and console terminal output r 
communicate diagnostic progress and error reports to the user. 

A console terminal is not required for operation but halts should net r 
enabled on a system without a console terminal. A QxSS (either QVS3 : 
QDSS) based display can be substituted for the console terminal. 

In order for the console program to operate, the processor must 1 
functioning to the point of executing instructions from the consol 

program ROM. 

The KA630 decodes the ROM addresses so that the same ROM appears mcr 
than once in the address space. The console program is written i 
position independent code so that it may be executed from any addres 
range and the KA630 uses this feature to selectively enable and disabl 
the external halt circuitry. If the console program is executing in ar¬ 
range of 20040000 to 2004FFFF (hex), external halt conditions ar 
ignored. If the console program is executing in the range of 2005011 
to 2005FFFF (hex) external halt conditions are honored and the consol 
program may be "halted" (whereupon it will immediately reenter at ic 
beginning to process the halt). 

The console program normally executes from the first address range whil 
the diagnostics software normally executes from the second addres 
range. 

For more information on the processor hardware, consult the KA 
Processor Specification. See also appendix B for a summary of 
hardware registers used by the console program. 


2.3 Software 

None - the console program runs standalone, it uses no other softw 
products. 


2.4 Services 

None - the console program requires no support services. 


3 SOFTWARE CAPABILITIES 

The console program is divided into six major components plus 
diagnostics. These components and their responsibilities are documen 


2 


ri r+ pj (l oi 



Digital Equipment Corporation - Software Specificacic 

SOFTWARE CAPABILITY 


in the sections that follow. Diagnostics are documented in "KA630 R1 
Diagnostic Specification". 

Note that throughout this document, the console program is ofre 
referred to simply as the "console". 

The console program receives control whenever the processor halts 
whether becasue of an external halt signal, the execution of a hal 
instruction, a serious system error or because of power-up. On any hal 
condition, the processor switches to physical addressing, saves the PI 
PSL and the ISP internally, encodes and saves the cause of the halt 
halt code and then branches to the start of the console program 
Upon entry, the console program always outputs the hex value "E" to 
console LED's to indicate that at least one instruction has 
executed. It then waits for power to stabilize by looping until BDR 
is set. 

When these common preliminaries are completed, the console pro 
checks to see if the halt is a power-up halt or a halt for some o 
reason. If it is a power-up halt, it begins the power-up sequ 
described in section 3.1. If it is not a power-up halt, control pa 
to the entry and dispatch code described in section 3.2. 


3.1 Power-up 

Upon power-up, the console automatically performs a variety of one tim 
operations. These operations initialize the processor and are needs 
only on power-up. 


3.1.1 Power-up Mode - 

On power-up, BDR<10:9> is interpreted as a power-up mode field. Th 
interpretation of the power-up mode field is shown in table 1. A 
discussed in the sections that follow, several power-up operations ar 
dependent on the power-up mode. 


Table 1: Power-up Modes 

Mode Language Prompt 


Diagnostics 


0 Prompt for language only if Run full diagnostics. 

TOY battery backup failed. 

1 Prompt for language on every Run full diagnostics, 

power-up. 
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Table 1 (cont.) 

Mode Language Prompt Diagnostics 


2 Set language to English. Run console terminal loop 

back tests. 

3 Set language to English. Run abbreviated diagnostics 


3.1.2 Power Stabilization And ROM Checksum Checks - 

Following the application of power, the processor first perfor 
hardware initialization and then control is transfered to the consc 
program ROM code. The common console startup functions were describ 
previously in section 3. Following their completion, on power-u 
control passes to the code described here. 

Beginning the power-up processing, the console code outputs the h 
value of "D" to the LED's indicating that the power stabilization wa 
is over. It then calculates a checksum of the console program ROM a 
checks it against the valid checksum stored in the ROM itself. If t 
computed checksum differs from the stored checksum, the code "hangs" 
a loop. If the checksum is the same, the power-up code proceeds to t 
next step. 


3.1.3 Console Program Initialization - 

The next step of the power-up initialization is location 
initialization of the memory needed for the console program itself, 
hex value of "C" is output to the LED's at the beginning of this step. 

During this step, the console ROM code searches top down throu 
available memory for a small contiguous block that will be used by t 
console program for writeable storage. This block consists of two pag 
for the console's direct use and additional pages for use to store 
bitmap of available memory. The amount of memory allocated to t 
bitmap varies according to the amount of memory available. 

Following initialization, memory appears as shown in figure 1. 
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Figure 1: Console Memory Map 

000000 +-+ 

I I 

| Low | 

I Memory | 


+-+ 

|Memory | 
j Bitmap | 

+-+ 

|Console| 
jMemory j 
+-+ 

I I 

(High | 

|Memory | 


XX0000 +-+ 


This memory is not tested during 
console initialization. It is tested 
later by the power-up memory 
diagnostics. 


Set by the memory diagnostics to 
map all good low memory. 

Used by the console program. 


Bad memory skipped over during console 
memory initialization. 


The console program memory is used by the console program for its stad- 
and other data structures. 

The bitmap is filled in later with a map of valid memory pages by th- 
power-up memory diagnostics and this bitmap is passed to the bootstrap 
as a map of valid memory. Beginning from the base of the bitmap, the 
first bit corresponds to the first page of low memory, the second bit tc 
the second page and so on. If the bit is set, the page is good, if the 
bit is clear, the page failed the memory test. The bitmap does not mar 
itself nor any other memory that follows the bitmap. Since syszer 
software is expected to use only pages marked as good in the bitmap, 
system software is not expected to modify the bitmap or the consols 
program memory. However, both the console program memory pages and the 
bitmap are checksumed by the console program to guard against accidental 
modification by the system software. 

If the console cannot locate enough memory for its own use and the 
bitmap, it "hangs". 

Following initialization of its memory, the console program clears 
CPMBX<1:0> (halt action), CPMBX<2> (bootstrap in progress flag) anc 
CPMBX<3> (restart in progress flag). 
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3.1.4 Battery Backup Check - 

The next thing done by the power-up operations is to check the TOY cloc 
to see if the battery backup has failed. If this has happened, time c 
year has been lost along with the contents of all the TOY clock RAM. I 
the battery backup has failed, the console stops the TOY clock, zerc 
the time and all TOY RAM and then initializes the TOY clock control ar 
status registers. The operating system must check TOY clock control ar. 
status register B and determine if the clock is stopped to know if th 
TOY clock contains a valid time. 

No change is made to the LED's during this operation. 


3.1.5 Test Interprocessor Communication Register - 

Next, the interprocessor communication register is tested. The he 
value "B" is output to the LED's during this test. 

This test is performed at this point as in addition to testing th 
register itself, this tests whether or not the Q22-bus is arbitratin 
properly. If it is not arbitrating, the processor will hang here 
Hanging here is preferable to hanging in the next step where we chec 
for QxSS video hardware on the bus. Were we to hang in the next ste 
without first checking the Q22-bus, the resulting LED display would b 
ambiguous as to which failed, the Q22-bus or the QxSS. 


3.1.6 Determining The Console Terminal Type - 


3.1.6.1 QxSS Determination - 

Next, if the processor is an arbiter processor, the console progra: 
checks for the presence or absence of a QxSS video display as th- 
console device. Either a QVSS or a QDSS will be detected. If th- 
processor is an auxiliary processor, this test is skipped. The he: 
value "A" is output to the LED's during this test. 

The QxSS is determined by testing for the presence of its CSR address a* 
tbs . (Both QVSS and QDSS use the same CSR address.) If there is m 
response, no QxSS is assumed present and the console program moves t> 
the console terminal determination code which follows. If a QxSS i. 
detected, it is initialized and a short diagnostic is executed. If the 
initialization and diagnostics succeed, the console will use the QxSS a. 
its console terminal (however, see appendix C) and skips the next ster 
and moves directly to the step described in section 3.1.7. If eithe: 
the initialization or the diagnostic fails, the system hangs. 
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3.1.6.2 Console Terminal Determination - 

If no QxSS is detected, it is assumed that normal a console terminal i 
connected to the console port or that NO terminal is connected. Th 
console program then next attempts to determined the type of termir.a 
connected. The value of ' , 9” is output to the LED's during this test. 

This determination is done by sending the terminal a device attribur 
request escape sequence. If the device responds with a recognizabl 
response, the terminal is classified as a video terminal versus a har 
copy terminal based on that response. This information is used when i 
console I/O mode to govern how command line editing is performed. Th 
terminal must respond in 1 second to the device query. If no respcns 
or the response is not recognized, the test is repeated two more time 
or until the response is understood. If the device never responds c 
the response isn't recognized, the terminal is classified as a hard ccr 
terminal. 

Terminal response will be recognized in either eight bit or seven bi 
mode. 

In addition to determining the presence or absence of a recognizable CP. 
console, this information is also used to determine if the termir.a 
supports the DEC multinational character set (MCS). The console prog 
assumes that all new terminals, VT2xx and beyond support MCS. If 
terminal does not support MCS, CPMBX<7: 4> is set to 2, forcing Engl 
as the console display language. 


3.1.7 Console Message Language Check - 

The console next outputs a hex value of "8" to the LED's and the 
determines the appropriate language to use for all console messages 
The algorithim used to determine the language appears below. Th 
console language is stored in CPMBX<7:4> (see appendix B) . 

1. If power-up mode (see table 1) is 2 or 3, set the consol 
language to English and exit. 

2. If power-up mode is 0 or if the value of CPMBX<7:4> is zero 
solicit the language from the user. If the user doesn' 
respond within 30 seconds, set the language to English (3) an 

exit. 


Remember that when the terminal is queried, if it isn't recognized a 
one that supports MCS, CPMBX<7:4> is set to 2, forcing English as th 
console language. English messages use the 7 bit subset of MCS. Also 
if a loss of power for the TOY clock is detected, the contents of th 
TOY RAM is zeroed meaning that step 2 of the algorithm above will caus 
the user to be prompted. 
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The format of the user query issued in step 2 is shown in Figure 2. 


Figure 2: User Language Prompt 


1) 

Danish 

7) 

Dutch 

2) 

German 

8) 

Norwegian 

3) 

English 

9) 

Portuguese 

4) 

Spanish 

10) 

Finish 

5) 

French 

11) 

Swedish 

6) 

Italian 




( 1 - 11 ): 


The text will be displayed using the DEC Multinational Character se 

extension. 

The user must respond by entering a value of 1 through 11 following th. 
question mark prompt, any other input will be rejected and the prcir. 
line will be issued again. Normal console input line editing featur 
(see section 3.6.1) will be available during input. 

If the console program has determined that a QxSS video display sysce 
is being used as the console, an additional step is required. The Q>:S 
display system uses the DEC LK201 keyboard which comes in 16 naticna 
variants. The keyboard variant cannot be determined by querying zi 
keyboard itself, it must be determined either from the language selecce 
or by means of an additiona menu selection. If French, German c 
English is specified as the language, the keyboard variant is ambiguou 
and the appropriate menu from figure 3 is displayed and the user i 
prompted to specify the which national keyboard variant is in use. I 
the user does not respond in 30 seconds, the last selection is assumed. 
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Figure 3: QxSS Keyboard prompts 


-French- 

1) Canada 

2) France/Belgium 

3) Switzerland 

(1. .3) : 

-German- 

1) Germany/Austria 

2) Switzerland 

( 1 .. 2 ) : 

-English- 

1) United Kingdom 

2) United States/Canada 

( 1 . . 2 ) : 


3.2 Entry/Dispatch 

Following the determination of the console language on power-up, c 
directly on entry from any other halt condition, the console dispatche 
to the appropriate code to service the halt. 

To determine what actions to take, the console program examines the hal 
code, the halt enable bit (BDR<14>), the console program mailbc 
register (CPMBX) and then acts in accordance with decision table show 
in table 2. 
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Table 2: Console Entry Decision Table 
BDR(14) Power-up CPMBX(1:0) Actions 


F 

F 

F 

F 

F 

T 

T 

T 

T 

T 


T 

F 

F 

F 

F 

T 

F 

F 

F 

F 


X Diagnostics, bootstrap, halt. 

0 Restart, bootstrap, halt 

1 Restart, halt. 

2 Bootstrap, halt. 

3 Halt 

X Diagnostics, halt. 

0 Halt. 

1 Restart, halt. 

2 Bootstrap, halt. 

3 Halt. 


A power-up entry is one where the processor halt code is 3. "X" mear. 

"don't care" and the meanings of the other CPMBX codes are defined i 

appendix B, section B.2.1. 


Multiple actions in table 1 mean that the first action is taken and i 
and only if it fails, the next action is taken. Diagnostics are a 
exception. If diagnostics fail the console will "hang" withcu 
attempting to bootstrap the processor. If they succeed, then the ne:-: 
action is taken. 

Note that because the KA630 does not support battery backup, it examine 
the halt code and does not attempt to perform restart operation 
following power-up. 


3.3 Diagnostics 

On power-up, the Entry/Dispatch code dispatches first to the diagnostic 
to check out the processor and memory before proceeding. Before doir. 
this, the console outputs the message "Performing normal system tests, 
to the console terminal. As each test is run, a code is displayed c 
the processor LED's and output to the console terminal as well, causir. 
a "countdown" to be displayed on both. 

The first diagnostic LED code is 8 so executing the diagnostic 
continues the LED countdown. The diagnostic codes are documented i 

table A-l along with all other codes. See figures 9 and 10 in section 
for console display formats. 

At the conclusion of all tests, the message "Tests completed." is outpu 
to the console terminal. 

If a diagnostic test detects a fatal error, an error message i 
displayed on the console, a summary message is displayed indicating tha 
the continued operation is not possible and then the system "hangs" 
leaving the test code in the LED's. If halts are disabled, the only wa 
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to clear the hung system is to turn the system off and then on agair 
If halts are enabled, the hung system may be cleared by manually haltir 
it, causing it to enter console command mode. 

Diagnostic software is fully documented in "KA630 ROM Diagnosti 
Specification". 


3.4 Restart 

The console can restart a halted operating system. To do so, th 
console searches system memory for the Restart Parameter Block (RPB), 
data structure constructed for this purpose by the operating system. I 
a valid RPB is found, the console restarts the operating system at a 
address specified in the RPB. 

The console keeps a "restart in progress" flag in the CPMBX registe 
which it uses to avoid repeated attempts to restart a failing operatir. 
system. An additional "restart in progress" flag may be maintained b 
software in the RPB. 

The console uses the following algorithm to restart the operatir. 
system: 

1. Check to see if the "restart in progress" flag in CPMBX is set 
If so, restart fails. 

2. Print the message "Restarting the operating system." on th 
console terminal. 

3. Set the restart in progress flag. 

4. Look for a Restart Parameter Block (RPB), left in memory by th 
operating system. If none is found, restart fails. 

5. Read the software restart in progress flag from bit<0> of th 
fourth longword of the RPB. If it is set, restart fails. 

6. Load SP with the address of the RPB plus 512. 

7. Load AP with the halt code. 

8. Display "0" in the console LED's. 

9. Start the processor at the restart address, which is read fro 
the second longword in the RPB. 


If restart fails, the console prints "Attempt to restart operatin 
system failed." on the console terminal. If the restart is successful 
the operating system must clear the restart in progress flag in CPMB 
(see appendix B for information on the CPMBX register). 
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The Restart Parameter Block is a page aligned control block, created 
the operating system. Its format is shown in figure 4. 


PB 


Figure 4: RPB Format 


+ 


+ 

I 

+ 

I 

+ 

I 

+ 


physical address of the RPB 


physical address of the restart routine 
checksum of the first 31 longwords of the restart routine 

software restart in progress flag (bit 0) 


Restart Parameter Block 
(RPB) 


The console uses the following algorithm to find a Restart Paramet 
Block: 

1. Search for a page of memory that contains its address in c 
first longword. If none is found, the search for an RPE h 
failed. 

2. Read the second longword in the page (the physical address 
the restart routine). If it is not a valid physical addres 
or if it is zero, return to step 1. The check for zero 
necessary to ensure that a page of zeros does not pass the re 
for a valid RPB. 

3. Calculate the 32 bit twos-complement sum (ignoring overflow 
of the first 31 longwords of the restart routine. If the s 
does not match the third longword of the RPB, return to step 

4. A valid RPB has been found. 

The same algorithm is used for both arbiter and auxiliary processors. 


3.5 Bootstrap 

The console can load and start (bootstrap) an operating system. To 
so, it searches for a 64 kilobyte segment of correctly functioni 
system memory, sets SP equal to the base address of the segment plus 5 
and then copies the primary bootstrap, called VMB, from the conso 
program ROM to the segment starting at the location specified by S 
The console program then branches to the first location in VMB whi 
then loads and starts the operating system. 
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To prevent a situation from occurring in which the console repeatedl 
tries and fails to bootstrap the operating system, it maintains 
"bootstrap in progress" flag in CPMBX. If a system bootstrap woul 
occur automatically but the flag is already set, the console assume 
that an attempt has already been made and has failed, so it does not tr 
again. 

The console uses the following algorithm to bootstrap the operatic 
system: 

1. If this bootstrap is the result of a console BOOT command, ski 
to step 4. 

2. Check to see if the "bootstrap in progress" flag is set. I 

so, the bootstrap fails. 

3. Print the message "Starting the operating system." on consol 
terminal. 

4. Set the bootstrap in progress flag. 

5. Locate a page-aligned 64 kilobyte segment of good memory. I 
such a segment cannot be found, the bootstrap fails. 

6. Initialize the Q22-bus I/O map as described below. 

7. Load the general registers for the primary bootstrap progra 
(VMB) as shown in table 3. 

8. Copy VMB from the console ROM to 512 bytes past the base of th 
good segment. 

9. Invoke VMB. If VMB fails, the bootstrap fails. 


If bootstrap fails, the console prints "Attempt to start operatir. 
system failed." on the console terminal. 

If the bootstrap is successful, the operating system must clear th 
bootstrap and restart in progress flags in the CPMBX register and clea 
the LED display by depositing a value of 0 in the BDR register (se 
appendix B). 
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Table 3: VMB Register Usage 

Rn Description 


RO 

R1 

R2 

R3 

R4 

R5 

RIO 

Rll 

AP 


ASCII device name (from BOOT command) or zero. 
Contents of KA630 Boot and Diagnostic Register 
Memory bitmap size in bytes. 

Address of memory bitmap. 

Unused. 

Software boot control flags (from BOOT command only). 
halt PC value, 
halt PSL value, 
halt code. 


SP 512 bytes past base of 64 Kb of good memory. 

During step 6 of the bootstrap process the Q22-bus I/O map i. 
initialized using the algorithm shown below. The main function of thii 
initialization is to preset the arbiter processor I/O map so that all 
unoccupied pages of the Q22-bus are mapped to the corresponding pages ir 
the first 4 Mb of local memory. (This is a MicroVAX I compatibility 
feature). Note that this is not done for auxiliary processors, any 
auxiliary Q22-bus I/O mapping must be coordinated with all other 
processors so all auxiliary processor I/O map registers are marke: 
invalid. 


1. Turn on IPCR<8>, the halt flag. 

2. Disable the I/O map by clearing IPCR<5>. 

3. If the arbiter processor, do the following for each I/O mat; 
register: 

a. Set the map register address bits to map the Q22-bus page 
to the corresponding local memory page. 

b. If the corresponding Q22-bus page is unoccupied, turn or. 
the valid bit. 

c. If the page is occupied, turn off the valid bit. 


If an auxiliary processor, turn off the valid bit in all map 
registers. 
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4. Enable the I/O map by setting IPCR<5>. 

5. If an auxiliary processor, loop until the IPCR<8> bit 
cleared. 


Steps 1 and 5 are present to perform a secondary function while th 
Q22-bus I/O map is initialized, namely to synchronize an auxiliar 
processor with its bootstrap host. See section 3.5.1.7 for additiona 
information. 


3.5.1 Primary Bootstrap Program (VMB) - 

VMB is the KA630 primary bootstrap. It is executed as the first part c 
a two part system bootstrap operation. VMB contains the code that: 

1. initializes the system control block (SCB), 

2. initializes an extended restart parameter block (RPB), 

3. initializes a PFN (page frame number) bit map and the relevan 
extended RPB fields, 

4. selects a bootstrap device, and 

5. performs a Files-11 0DS2, boot block, ROM or down-line load c 
the secondary bootstrap. 


The secondary bootstrap continues the bootstrap operation. For KA63 
systems, primary bootstrap operations are defined by VMB, secondar 
bootstrap are defined by the operating system being booted. 

VMB finds the bootstrap device in one of three ways: 

1. If the bootstrap is the result of a console bootstrap comman: 

and a device name is specified in the command, that device is 

searched for the secondary bootstrap. 

2. If not the result of a console bootstrap command or if nc 
device name is specified, VMB searches first for a bootable 
disk, then for a TK50 (Maya) tape unit, then for MRV11 PROM, 
and finally for a DEQNA for a down-line bootstrap. 

3. If the bootstrap is the result of a halt with CPMBXCl:0> equal 

to 2 - a request from the operating system to reboot the syster 

- the bootstrap device used to previously bootstrap the 
operating system is used (as well as the same command flags). 
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When a VMB bootstrap attempt fails, it halts. 


3.5.1.1 Bootstrap Devices - 

The following bootstrap devices are supported: 

1. RQDX, QDA and Aztec MSCP disk controllers. VMB can boot frc 
any disk unit supported by a MSCP QD or Aztec disk controller 
Units supported by RQDX are RX50, RD51, RD52 and RD53. Uni- 
supported by QDA are tbs . For purposes of the BOOTSTR.- 
command, units are designated DUAO, DUA1, and so on. The firs 
controller must be configured at the Q22-bus address of 177215 
(octal) and Q22-bus interrupt vector of 154 (octal) 
Additional controllers are located in floating CSR and vectc 
space. 

2. DEQNA Ethernet adapter. This controller connects to a 
Ethernet cable. For purposes of the BOOTSTRAP command, thi 
device is designated XQAO. The controller must be configure 
at Q22-bus address 1774440 (octal) and Q22-bus vector of tbs . 

3. MRV11 PROM. This is a Programmable Read Only Memory board 
For purposes of the BOOTSTRAP command it is designated PRAO. 

4. TMSCP tape controller (TK50). VMB can boot from any tape uni 
supported by the the TK50 TMSCP tape controller. For purpose 
of the BOOTSTRAP command it is designated tbs . The controlle 
must be configured at Q22-bus address tbs and Q22-bus interrut 
vector tbs . Additional controllers are not be supported. 


3.5.1.2 Bootstrap Command FI - When a bootstrap is invoked via 
BOOTSTRAP command, the user can specify several boot command flags t 
bit encoding the flags in a flag word specified with the "/R5: 
qualifier. These command flags are described in table 4. 


Table 4: 
Bit 

Number 


VMB Bootstrap Command Flags 

Value Flag Name 

(Hex) 


Description 


0 00000001 CONVERSATION Conversational bootstrap. 
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Bit Value Flag Name 

Number (Hex) 


3 00000008 BOOTBLOCK 


4 00000010 DIAGNOSTIC 


6 00000040 HEADER 


8 00000100 SOLICIT 


9 00000200 HALT 


<31: 2 8> X0000000 TOPSYS 


Description 


Secondary bootstrap from bcc 
block. When this bit is set, VO 
reads logical block number 0 of 
boot device and tests it 
conformance with the boot bl 
format. If in conformance, 
block is executed to continue 
bootstrap. No attempt to perform 
Files-11 bootstrap is made. 


Diagnostic bootstrap. When this 
is set the secondary bootstrap 
called [SYS0.SYSMAINT] DIAGBOOT.E 


Image header. If this bit is 
set, VMB transfers control to 
first location of the second 
bootstrap. If this bit is set, 
transfers control to the addr 
specified by the file's im 
header. 


File name solicit. When this bit 
set, VMB prompts the operator 
the name of the secondary bootst 
file. 


Halt before transfer. When this bi 
is set, VMB halts befor 
transfering control to th 
secondary bootstrap. 

X can be any value from 0 through 
(hex). This flag changes the tc 
level directory name for syste 
disks with multiple operatir. 

systems. For example, if X=l, th 
top level directory name is [SYS1 
. . .] . 


3.5. 1.3 Booting From Disk - 

For VMB to boot using a MSCP disk controller, the first controller mus 
be configured at 772150(octal) and subsequent controllers must t 
properly configured in their appropriate floating CSR and vector slots 
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Table 4 (cont.) 

Bit Value Flag Name 

Number (Hex) 


3 00000008 BOOTBLOCK 


4 00000010 DIAGNOSTIC 


6 00000040 HEADER 


8 00000100 SOLICIT 


9 00000200 HALT 


<31:28> X0000000 TOPSYS 


Description 


Secondary bootstrap from be. 
block. When this bit is set, II 
reads logical block number 0 of c: 
boot device and tests it f; 
conformance with the boot bic: 
format. If in conformance, cl 
block is executed to continue tl 
bootstrap. No attempt to perform 
Files-11 bootstrap is made. 

Diagnostic bootstrap. When this t: 
is set the secondary bootstrap i 
called [SYS0 . SYSMAINT] DIAGBOOT". EXI 

Image header. If this bit is r.z 
set, VMB transfers control to cl 
first location of the seconds: 
bootstrap. If this bit is set, : 
transfers control to the adore; 
specified by the file's ima: 
header. 

File name solicit. When this bit i 
set, VMB prompts the operator 
the name of the secondary bootsc 
file. 

Halt before transfer. When this 
is set, VMB halts bef 
transfering control to 
secondary bootstrap. 

X can be any value from 0 throug 
(hex) . This flag changes the 
level directory name for sys 
disks with multiple operat 
systems. For example, if X=l, 
top level directory name is [SY 
. . . ] . 


3.5.1.3 Booting From Disk - 

For VMB to boot using a MSCP disk controller, the first controller mus 
be configured at 772150 (octal) and subsequent controllers must t 
properly configured in their appropriate floating CSR and vector slots 
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When VMB determines that a controller is present, it searchs in order : 
increasing unit number for an accessible unit with a removable volume 
If it finds such a unit with a volume present, VMB proceeds as describe 
below. If it finds no such volume, it repeats the search but this tin 
it checks for non-removable volumes. If by this time no accessibl 
volume is found, it checks for the next controller and repeats ti 
checks described. If no more controllers are found, the disk boc 
fails. 

If an accessible volume is located, VMB then determines if it is 
Files-11 volume. If it is, it searches the volume for "[SYSO.SYSZXZ 
SYSBOOT.EXE" which contains the secondary bootstrap. If this file i 
found, VMB loads and executes it (performs a secondary bootstrap). 

If the volume is not a Files-11 volume, VMB then checks logical bloc 
number zero of the volume for a valid bootblock (see figure 5). If th 
bootblock is a valid bootblock VMB loads and executes the seconder 
bootstrap specified in the bootblock. If there is not a valid bootbloc 
present, the search resumes for the next accessible disk. 

Note that the bootstrap process can be altered by boot command flags 
Information on the effect of boot command flags is given in table 4. 


Figure 5: Bootblock Format 


I 

+ 


+ 


+ 0 : 

+— 

i 

i 

i 

n 

i 

any value 

+ 4 : 

i 


low LBN 


i 

high LBN 


+ 


+ 


+ 


BB + 2*n 


+ 0 


+ 4 : 


+ 8 : 


+ 12 : 


+ 16: 


---+- + ----- 

check byte | k | 0 

_]_ _L 

1 

. i . 

18 (hex) 

any value 1 1 or 81 

*“ T “* — “ 

1 

0 

size in blocks of the image 



load offset from default load address 

offset into image to start execution 











+ 20: | 


sum of previous three longwords 


BB+0: 
BB+2 : 


These two bytes can have any value. 

This value is the word offset from the start 
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the bootblock to the identification ar^ 



described below. 

BB+3 : 

This byte must be one. 

BB+4 : 

This longword contains the logical block nirrxe 
(word swapped) of the secondary image. 

BB+ (2*n) +0 : 

This byte defines the expected instruction se: 
18(hex) means VAX. 

BB+(2*n) +1 : 

This byte defines the expected controller type 
0 means unknown. 

BB+(2*n)+2: 

This byte defines the file structure on th 
volume, it may be any value. 

BB+(2*n) +3: 

This byte must be the ones complement of the so 
of the previous three bytes. 

BB+(2*n) +4: 

This byte must be zero. 

BB+ ( 2 * n )+5: 

This byte must be 1 or 81 (hex). This bye 

defines the version number of the fcrr.a 

standard and the type of disk. The version i 
1, the high bit is 0 for single sided, 1 fc 
double sided. 

BB+(2*n) +6: 

These two bytes must be zero. 

BB+(2*n)+8 : 

This entry is a longword containing the size i 
blocks of the secondary bootstrap image. 

BB+(2*n)+12 : 

This entry is a longword containing a loa 
offset (usually zero) from the default loa 
address of the secondary bootstrap. 

BB+(2*n)+16: 

This entry is a longword containing the bye 
offset into the secondary bootstrap wher 
execution is to begin. 

BB+(2*n)+20: 

This entry is a longword containing the sum c 
the previous three longwords. 


3.5.1.4 Booting From Tape - 

If no bootable disk is found, VMB attempts to bootstrap from a TK5 
tape. The TK50 must be configured at <tbs> octal to be recognized b 
VMB. 
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If a TK50 is present, VMB determines if a tape is loaded and the ur.ic i 
online. If so, VMB rewinds the tape and searches for the fil 
TAPEBOOT.EXE. (The user may specify an alternative file name by seccir. 
the SOLICIT bit in the software command register [see table 4]). I 
this file is found, VMB loads and executes it. Normally this file wcul 
contain a program to load an operating system from tape onto a sysce 
disk. 

Note that a TAPEBOOT.EXE program to load a disk from tape is not a par 

of this project. 

If a user has both disks and tape, and a disk is bootable, to boot ire 
tape the user must either take all bootable disks offline or explicicl 
boot the TK50 via the console boot command. 


3.5.1.5 Booting From PROM - 

If neither disk nor tape is bootable, VMB checks for a PROM bootstrap. 

To locate a PROM bootstrap, VMB searches the Q22-bus address range fr 
low to high addresses in 16 page chuncks looking for readable memcr 
If the first six longwords of any such page contains a valid "signa 
block" (identical to the second part of the bootblock format, see fi 
5), VMB copies the PROM image to main memory and then transfers con 
to it. 

Note that while defined as a MRV11 PROM or equivalent bootstrap, YM 
doesn't actually require that the signature block or the bootstrap cot 
be in PROM, it could be in ROM, nonvolatile RAM or, as described i 
section 3.5.1.7, it could be loaded into another KA630's RAM and mappe 
to the Q22-bus. 


3 .5.1.6 Booting From DEQNA - 

If no other bootstrap device is found, VMB attempts to bootstrap fre: 
the DEQNA ethernet controller. In this case, the secondary bootstrap i. 
downline loaded from a host on the Ethernet using DECNET Low-leve. 
Maintenance Protocol (MOP) Version 3.0. The DEQNA module must b- 
configured at Q22-bus address 774440 (octal). 

The downline load process consists of the following steps: 

1. VMB performs local testing of the DEQNA. If the tests fail 
the bootstrap attempt fails and the three LED's on the DEQNJ 
are set according to the problem detected. The LED setting, 
and their interpretations are: 

o 3 LED's on: DEQNA initialization failure. 
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o 2 LED's on: internal loopback failure, 
o 1 LED on: external loopback failure. 


VMB transmits a Program Request MOP message over the Ethernet 
The message destination is the Load Assistant Multicast addref 
AB-00-00-01-00-00. The message source address is the DEQNA' 
station address (from DEQNA PROM). The MOP program type i 
operating system. 

3. VMB waits approximately 30 seconds to receive a response. I 
it does not receive a response it retransmits the request ever 
thirty seconds for a total of 2 minutes. If a response is nc 
received in two minutes, the bootstrap fails. 

4. VMB accepts MOP Load Messages and loads the data into memory 
terminating when the final message is received as indicated i 
the MOP message protocol. If the interval between lea 
messages exceeds 30 seconds, VMB restarts the DEQNA bootstra 
at step 2. 


3.5.1.7 Booting An Auxiliary Processor - 

VMB bootstraps an auxiliary processor via the ROM bootstrap protocol 
Recall from section 3.5 the Q22-bus initialization algorithm: 

1. Turn on IPCR<8>, the halt flag. 

2. Disable the I/O map by clearing IPCR<5>. 

3. Initialize the I/O map. 

4. Enable the I/O map by setting IPCR<5>. 

5. If an auxiliary processor, loop until the IPCR<8> bit i 
cleared. 


(Note that whenever the console program is entered, it turns of 
IPCR<8>.) Steps 1 and 5 ensure that an auxiliary will loop until serr. 
other processor clears IPCR<8>. When another processor, the bootstra 
host, clears IPCR<8>, the auxiliary proceeds with the bootstrap. Thi 
synchronization gives the arbiter processor control over th 
bootstrapping of all auxiliary processors. 

An auxiliary processor cannot directly bootstrap itself from any of th- 
normal bootstrap devices so VMB on an auxiliary checks only for the RCX 
bootstrap described in section previously. The ROM bootstrap may b 
either a block of nonvolatile memory on the Q22-bus bus or the bootstrap 
host can construct an equivalent bootstrap in RAM. In either case th 
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auxiliary will not proceed with the bootstrap until the bootstrap hc£ 
clears IPCR<8>. The bootstrap host in turn should not clear r; 
auxiliary's IPCR<8> unless IPCR<5> is clear. 


3.5.2 Secondary Bootstrap Program - 

The secondary bootstrap program is invoked as the second part of 
system bootstrap. Following successful execution of the primal 
bootstrap, the secondary bootstrap has either been loaded into memory ; 
located in ROM. It is the responsibility of the secondary bootstrap a 
complete the bootstrap of the processor. 

VMB calls the secondary bootstrap with the processor in the followir. 
state: 

o The processor is running in kernel mode on the interrupt sia: 
at IPL 31(hex). 

o Rll contains the base address of the extended RPB (figure c 
built by VMB. 

o AP contains the address of the secondary bootstrap argur.er. 
list (figure 7). 

o SP contains the address of the top of the stack plus 4, wr.ic 
is also the address of the beginning of the secondary bootsrra 
(figure 8 for a map of memory). 

o SCBB (internal processor register) contains the address of th 
SCB built by VMB. 


Note that the first four longwords of the VMB built extended RPB wcul 
not be recognized as a valid RPB by the console restart algorithm. I 
is up to the secondary bootstrap or the operating system itself t 
complete the RPB if automatic restart is desired. 
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Figure 6: Extended RPB 
Offset (hex): 

+-f 

00: I address of the extended RPB | 

+ — — “*———— — —————————— ————————— — — —————— — — — — — — — — — — — 4* 

04: | 0 | 

+-+ 

08: | 0 I 

+-+ 

0C: | 0 | 

+ — — — — — — — — — — — — — — — — — — — — — — — — — — — ————————————— — — — — 4 * 

10: | PC at restart/halt I 

+-+ 

14: | PSL at restart/halt I 

+-+ 

18: | halt code | 

+-+ 

1C: | VMB input register R0 I 

-j-— — —---—————————— -f- 

20: | VMB input register R1 | 

— — — — — — — — —--. — — — — — — — .-1- 

24: | VMB input register R2 | 

+-+ 

28: I VMB input register R3 | 

— — — — —- — “ —- — — — — — — — — — — — — — — — — — — — — —-— — — — — —- — + 

2C: | VMB input register R4 | 

-j- — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —-— — — 

30: | VMB input register R5 | 

H-— — — — —-— —-— — — — — — — — —---—-b 

34: | two longwords reserved | 

H-— — -—-— —-— —-h 

3C: I disk block address of secondary bootstrap | 

-)-—-_ —— — ——-—-h 

40: I size of secondary bootstrap file in blocks | 

-j — — — — —-— — — — — — — — — — — — — — — — — — — —-1_ 

44: | descriptor of PFN bitmap (two longwords) I 

-J-— —---*---f 

48: I number of good physical pages | 

4 -— — —-—-— — —------- 1 - 

4C: I reserved | 

4“—— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 4* 

50: | physical CSR address of boot device I 

H---—-—-1- 

54: | four longwords reserved | 

68: |secondary bootstrap file name (40 characters) | 

H- —-(- 

90: | eight longwords reserved I 

-i- ————————— 

B0: I system control block base address | 

-i- 1- 
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Figure 7: Secondary Bootstrap Argument list 


+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -f 

(AP)+00: | 12 | 

+-+ 

(AP)+04: | reserved I 

4 * —-— — — — — — — — — — — — — — — — — — — — — — —-— — — — — — — — — — — — 4 - 

(AP)+08: I reserved I 

4 — — — — — — — — — — — — — — — — — — — — — — — — — — —-— —---— — — ——+ 

(AP)+12: | lowest valid PFN I 

4. — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —-j- 

(AP)+16: I highest valid PFN | 

+-+ 

(AP)+24: | PFN map size in bytes I 

4— — — — — — — — — — — — — — — — — — — — — — — -—-*-— 4- 

(AP)+28: I address of PFN bitmap | 

-|-— — — — — — — — — — — — — — — — — — — — — — — — -— — — — — — — —-f 

(AP)+32: | reserved I 

4-- — — — — — — — — — — — — — — — — — — — — — — — — — —-— —-—-— —-— — — 

(AP)+36: I reserved | 

4— — — — — — — — — — — — — — — — — — — —-— — — — — — — — — — — — — — — — — — — — — — — —f 

(AP)+40: I processor ID (8????) | 

+-+ 

(AP)+44: | reserved | 

4 “ — — — — — — — — — — — —-— — — —-—-— —-— 4 * 

(AP)+48: I reserved | 

+-+ 


Figure 8: Secondary Bootstrap Memory Map 

4* — — — — — — — — — — — — — — — — — — — —-— —-—-— —-— — 4* 

Rll: | Extended RPB built by VMB | 

4-- --— *-f 

+ 200(hex): | VMB | 

+-+ 

+ ????(hex): | 2 page SCB used by VMB I :SCEE 

+-+ 

+ ????(hex): | 8 page PFN bitmap [ 

+-+ 

+ ????(hex): | 4 page stack for Secondary Bootstrap | 

4-— — — — — — — — — — — — — — — — — — — — — — — — — —-—-— —-— — — — —-— — — 4- 

+ ????(hex): | | :SP 

j Secondary Bootstrap j 

I . I 

I . I 

I I 

4* —-—— — — — — — — — — — — — — — — — — — — — — —---— — — — — — 

+10000(hex): 
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3.6 Console I/O Mode (System Halted) 

When the KA630 is "halted", the operator controls the system through ch 
console terminal using the console command language. The consol 
terminal is in "Console I/O Mode". The console prompts the operator f~ 
input with the string ">»". 


3.6.1 Console Control Characters - 

In console I/O mode, several characters have special meanings. 

o carriage return - ends a command line. No action is taken on 
command until after it is terminated by a carriage return, 
null line terminated by a carriage return is treated as 
valid, null command. No action is taken, and the consol 
re-prompts for input. Carriage return is echoed as carriac 
return, line feed. 

o rubout - when the operator types rubout, the console delene 
the character that the operator previously typed. What appear 
on the console terminal depends on whether the terminal is 
video terminal or a hardcopy terminal. 

For hard copy terminals, when a rubout is typed, the consol 
echoes with a backslash (\), followed by the character beir. 
deleted. If the operator types additional rubouts, th 
additional characters deleted are echoed. When the operacc 
types a non-rubout character, the console echoes anothe 
backslash, followed by the character typed. The result is t 
echo the characters deleted, surrounding them with backslashes 
For example: 

The operator types: EXAMI;E<rubout><rubout>NE<CR> 

The console echoes: EXAMI;E\E;\NE<CR> 

The console sees the command line: EXAMINE<CR> 


For video terminals, when rubout is typed the previou 
character is erased from the screen and the cursor is restore 

to its previous position. 

The console does not delete characters past the beginning of 
command line. If the operator types more rubouts than ther 
are characters on the line, the extra rubouts are ignored. I 
a rubout is typed on a blank line, it is ignored. 

o control-U - the console echoes " A U<CR>", and deletes the entir 
line. If control-U is typed on an empty line, it is echoed 
and otherwise ignored. The console prompts for anothe 
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command. 

o control-S - stops output to the console terminal unt: 
control-Q is typed. Control-S and control-Q are not echoec 
Control-C, control-0, and BREAK also clear control-S. 

o control-Q - resumes output to the console terminal. Additions 
control-Q's are ignored. Control-S and control-Q are nc 
echoed. 

o control-0 - causes the console to throw away transmissions t 
the console terminal until the next control-0 is enterec 
Control-0 is echoed as ,,A 0"<CR> when it disables output, but i 
not echoed when it reenables output. Output is reenabled i 

the console prints an error message, or if it prompts for 

command from the terminal. Displaying a REPEAT command doe 
not reenable output. When output is reenabled for reading 
command, the console prompt is displayed. Output is als 
enabled by entering program I/O mode, by BREAK and k 

control-C. Control-0 clears control-S. 

o control-R - causes the console to echo <CR><LF> followed by tk 
current command line. This function can be used to improve th 
readability of a command line that has been heavily edited. 

o control-C - causes the console to echo ,,A C" and to abor 
processing of a command. Control-C has no effect as part of 
binary load data stream. Control-C clears control-S, ar. 

reenables output stopped by control-0. When control-C is type 
as part of a command line, the console deletes the line as i 
does with control-U. 

o BREAK - If the console is in console I/O mode, BREAK i 
equivalent to control-C, but is echoed as ?,A P". If the consol 
is in program I/O mode and halt is disabled, BREAK is ignored 
If the console is in program I/O mode and halt is not disabled 
BREAK causes the processor to halt and enter console I/O mode. 


Control characters are typed by pressing the character key whil 
simultaneously holding down the control key. 

If an unrecognized control character is typed (a control character her 
means a character with an ASCII code less than 32 decimal [CO] c 
between 128 and 159 decimal [Cl]) it is echoed as up arrow followed k 
the character with ASCII code 64 greater. For example, BEL (ASCII cod 
7) is echoed as ,,A G", since capital G is ASCII code 7 + 64=71. When 

control character is deleted with rubout, it is echoed the same way 
After echoing the control character, the console processes it like 
normal character. Unless the control character is part of a comment 
the command will be invalid, and the console will respond with an errc 
message. Note that control codes from 128 to 159, the Cl control codes 
cannot be entered by any present Digital terminal. The fact that bot 
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the character with code 7 and the character with code 135 will both ec: 
as " A G" is not expected to have any practical consequences. 


3.6.2 Console Command Syntax - 

The console accepts commands of lengths up to 80 characters. Lon 
commands are responded to with an error message. The count does 
include rubouts, rubbed out characters, or the terminating carri 
return. 

Commands may be abbreviated. Abbreviations are formed by droppir 
characters from the end of a keyword. All commands are recognized frc 
their first character. 

Multiple adjacent spaces and tabs are treated as a single space by z: 
console. Leading and trailing spaces and tabs are ignored. 

Command qualifiers can appear after the command keyword, or after ar. 
symbol or number in the command. 

All numbers (addresses, data, counts) are in hexadecimal. (Ncze 
though, that symbolic register names include decimal digits.) Hex digit 
are 0 through 9, and A through F. The console does not distinguis 
between upper and lower case either in numbers or in commands. Both ar 
accepted. 


3.6.3 Console Command Keywords - 
Processor control commands: 
o INITIALIZE 
o START <address> 
o CONTINUE 
o HALT 

o BOOT <device> 
o UN JAM 

Data transfer commands: 

o EXAMINE <address> 
o DEPOSIT <address> <data> 
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o X <address> <count> 
Console control commands: 
o FIND 

o REPEAT <command> 
o TEST 

o I <comment> 


3.6.4 References To Processor Registers And Memory - 

The KA630 console is implemented by macrocode executing from ROM. Fc 
this reason, the actual processor registers may not be modified by th 
command interpreter. When the console is entered, the console saves th 
processor registers in console memory and all command references to the 
are directed to the corresponding scratch page locations, not to hi 
registers themselves. When the console reenters program mode, the save 
registers are restored and any changes become operative only ther. 
References to processor memory are handled normally except where note 
below. 

The console uses memory at the top of the available system memory fc 
its own use (see figure 1). References to the console memory pages t 
EXAMINE and DEPOSIT commands must be qualified by the "/U" qualifier 
(Access is primarily to simplify debugging of the console program.) Th 
binary load and unload command may not reference the console mencr 
pages. 


3.6.5 Console Commands - 


3.6.5.1 BOOT - 

BOOT [<qualifier list>] [<device>] 

The device specification is of the format 'ddcu f , where ' dd' is a tw 
letter device mnemonic, ' c r is an optional one digit controller number 
and 'u' is a one digit unit number. 

The console initializes the processor and starts VMB running. (See th 
section on System Bootstrapping.) VMB boots the operating system fro 
the specified device. The default bootstrap device is determined a 
described in the section on system bootstrapping. 
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Qualifiers: 

o /R5:<data> - After initializing the processor and befcr 
starting VMB, R5 is loaded with the specified data. Thi 
allows a console user to pass a parameter to VMB. (To remai 
compatible with previous processors, /<data> will also t 
recognized to have the same result.) 


3.6.5.2 CONTINUE - 

CONTINUE 

The processor begins instruction execution at the address currer.zl 
contained in the program counter. Processor initialization is nc 
performed. The console enters program I/O mode. 

If upon entry the console program is unable to preserve the machir. 
state, either because it was a power-up or because it was unable c 
locate a scratch page on the interrupt stack, the CONTINUE command wil 
be rejected. 


3.6.5.3 DEPOSIT - 

DEPOSIT [<qualifier list>] <address> <data> 

Deposits the data into the address specified. If no address space c 
data size qualifiers are specified, the defaults are the last addres 
space and data size used in a DEPOSIT or EXAMINE command. Afre 
processor initialization, the default address space is physical memory 
the default data size is long, and the default address is zero. 

If the specified data is too large to fit in the data size to b 
deposited, the console ignores the command and issues an error response 
If the specified data is smaller that the data size to be deposited, i 
is extended on the left with zeros. 

The address may also be one of the following symbolic addresses: 

o PSL - the processor status longword. No address spac 

qualifier is legal. When PSL is examined, the address space i 
identified as "M" (machine dependent). 

o PC - the program counter (general register 15). The addres 
space is set to /G. 

o SP - the stack pointer (general register 14). The addres 
space is /G. 
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o Rn - general register ' n'. The register number is in decima 
The address space is /G. For example: 

D R5 1234 is equivalent to D/G 5 1234 


D RIO 6FF00 is equivalent to D/G A 6FF00 

o - the location immediately following the last locaci 

referenced in an examine or deposit. For references 
physical or virtual memory spaces, the location referenced 
the last address, plus the size of the last reference (1 f 
byte, 2 for word, 4 for long). For other address spaces, c 
address is the last address referenced, plus one. 


o '- the location immediately preceding the last locaci 
referenced in an examine or deposit. For references 

physical or virtual memory spaces, the location referenced 
the last address minus the size of this reference (1 for bye 
2 for word, 4 for long). For other address spaces, the addre 
is the last addressed referenced minus one. 


o '*' - the location last referenced in an examine or deposit. 

o '- the location addressed by the last location referenced 
an examine or deposit. 


Qualifiers: 

o /B - The data size is byte. 

o /W - The data size is word. 

o /L - The data size is longword. 

o /V - The address space is virtual memory. All access a 
protection checking occur. If the access would not be allow 
to a program running with the current PSL, the console issu 
an error message. Virtual space DEPOSITS cause the PTE<M> b 
to be set. If memory mapping is not enabled, virtual address 
are equal to physical addresses. 

o /P - The address space is physical memory. 

o /I - The address space is internal processor registers. The 

are the registers addressed by the MTPR and MFPR instructions 

o /G - The address space is the general register set, RO throu 

PC. 

o /U - Access to the console scratch page is allowed. Th 
qualifier also disables virtual address protection checks. 
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o /N:<count> - The address is the first of a range. The cons: 
deposits to the first address, then to the specified number 
succeeding addresses. Even if the address is the symbol 
address the succeeding addresses are at larger addresse 

The symbolic address specifies only the starting address, r. 
the direction of succession. For repeated references 
preceding addresses, use "REPEAT DEPOSIT - <data>". 

For example: 

D/P/B/N:IFF 0 0 Clears the first 512 bytes of physic 

memory. 

D/V/L/N:3 1234 5 Deposits 5 into 4 longwords starting 

virtual address 1234. 

D/N:8 RO FFFFFFFF Loads general registers RO through 

with -1. 

D/N:200 - 0 Starting at previous address, clear 5 

bytes. 

If conflicting address space or data sizes are specified, the consc 
ignores the command and issues an error response. 


3.6.5.4 EXAMINE - 

EXAMINE [<qualifier list>] [<address>] 

Examines the contents of the specified address. If no address 
specified, "+" is assumed. The address may also be one of the symbol 
addresses described under DEPOSIT. 

Qualifiers: 

The same qualifiers may be used on EXAMINE as may be used on DEPOSIT. 

RESPONSE: <tab><address space identifier> <address> <tab> <data> 

The address space identifier can be: 

o P physical memory. Note that when virtual memory 

examined, the address space and address in the response are t 
translated physical address. 

o G - general register. 

o I - internal processor register. 

o M - machine dependent (used only for display of the PSL). 
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3.6.5.5 FIND - 

FIND [<qualifier list>] 

The console searches main memory starting at address zero for 
page-aligned 64 kilobyte segment of good memory, or a restart paramece 
block (RPB). If the segment or block is found, its address plus 512 i 
left in SP. If the segment or block is not found, an error message i 
issued, and the contents of SP are UNPREDICTABLE. If no qualifier i 
specified, /RPB is assumed. 

Qualifiers: 

o /MEMORY - search memory for a page aligned segment of gcc 
memory, 64 kilobytes in length. The search includes 
read/write test of memory and leaves the contents of memcr 
UNPREDICTABLE. 

o /RPB - search memory for a restart parameter block. See 
section 3.4 for the search algorithm. The search leaves 
contents of memory unchanged. 


3.6.5.6 INITIALIZE 


INITIALIZE 


A processor initialization is performed, 
set (all values are hexadecimal): 


The following registers a: 


PSL 

IPL 

ASTLVL 

SISR 

ICCS 

RXCS 

TXCS 

MAPEN 


041F0000 

IF 

4 

0 

0 

0 

80 

0 


All other registers are UNPREDICTABLE. 

The previous console reference defaults (the defaults used to fill i. 
unsupplied qualifiers for DEPOSIT and EXAMINE commands) are set t 
physical address, longword size and address 0. 


3.6.5.7 HALT - 
HALT 
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The HALT command has no affect, the processor is already halted when 
console I/O mode. 

RESPONSE: Already halted 


3.6.5.8 REPEAT - 
REPEAT <command> 

The console repeatedly displays and executes the specified command. Th 
repeating is stopped by the operator typing control-C. Any vali 
console command may be specified for the command with the exception c 
the REPEAT command. 

RESPONSE: <dependent upon command specif ied> 


3.6.5.9 START - 
START [<address>] 

The console starts instruction execution at the specified address. I 
no address is given, the current PC is used. If no qualifier i 
present, macroinstruction execution is started. If memory mapping i 
enabled, macroinstructions are executed from virtual memory. The STAR 
command is equivalent to a DEPOSIT to PC, followed by a CONTINUE. K 
INITIALIZE is performed. 


3.6.5.10 TEST - 
TEST [<test number>] 

The console invokes a diagnostic test program denoted by ctest number> 
Valid test numbers are 3 through 7 and hexidecmal B. 

See "KA630 ROM Diagnostic Specification" for information on diagnosti 
tests and their corresponding test number codes. 


3.6.5.11 UNJAM - 

An I/O bus reset is performed. 
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3.6.5.12 Binary Load And Unload Command - 
X <address> <count> <CR> <checksum> 

The X command is for use by automatic systems communicating with ri 
console. It is not intended for use by operators. The console loads ; 
unloads (that is, writes to memory, or reads from memory) the specific 
number of data bytes, starting at the specified address. 

If bit 31 of the count is clear, data is to be received by the consols 
and deposited into memory. If bit 31 of the count is set, data is to 1 
read from memory and sent by the console. The remaining bits in re¬ 
count are a positive number indicating the number of bytes to load : 
unload. 

The console accepts the command upon receiving the carriage return. 11 
next byte the console receives is the command checksum, which is r.c 
echoed. The command checksum is verified by adding all cor-iar. 
characters, including the checksum, (but not including the terminaoir. 
carriage return or rubouts or characters deleted by rubout), into an 
bit register initially set to zero. If no errors occur, the resuir i 
zero. If the command checksum is correct, the console responds with ni 
input prompt and either sends data to the requester or prepares a 
receive data. If the command checksum is in error, the console respond 
with an error message. The intent is to prevent inadvertent operas; 
entry into a mode where the console is accepting characters from rl 
keyboard as data, with no escape sequence possible. 

If the command is a load (bit 31 of the count is clear), the consol 
responds with the input prompt, then accepts the specified number c 
bytes of data for depositing to memory, and an additional byte c 
received data checksum. The data is verified by adding all dan 
characters and the checksum character into an 8 bit register initiall 
set to zero. If the final contents of the register is non-zero, cl 
data or checksum are in error, and the console responds with an errc 
message. 

If the command is a binary unload (bit 31 of the count is set), rt 
console responds with the input prompt, followed by the specified numbe 
of bytes of binary data. As each byte is sent it is added to a checksu: 
register initially set to zero. At the end of the transmission, the 2' 
complement of the low byte of the register is sent. 

If the data checksum is incorrect on a load, or if memory errors or lir. 
errors occur during the transmission of data, the entire transmission i 
completed, and then the console issues an error message. If an errc 
occurs during loading, the contents of the memory being loaded ar 
UNPREDICTABLE. 

Echo is suppressed during the receiving of the data string ar. 
checksums. 


34 



Digital Equipment Corporation - Software Specificati. 

SOFTWARE CAPABILITY 


It is possible to control the console through the use of the conscl 
control characters (control-C, control-S, control-O, etc.) during 
binary unload. It is not possible during a binary load, as all receive 
characters are valid binary data. 

Data being loaded with a binary load command must be received by t: 
console at a rate of at least one byte per second. The command checks: 
that precedes the data must be received by the console within 10 seconc 
of the <CR> that terminates the command line. The data checksum must i 
received within 10 seconds of the last data byte. If any of the: 
timing requirements are not met the console aborts the transmission 1 
issuing an error message and prompting for input. 

The entire command, including the checksum, may be sent to the consol 
as a single burst of characters at the console's specified characne 
rate. The console is able to receive at least 4K bytes of data in 
single 'X' command. 


3.6.5.13 Comment - 
! <comment> 

The comment command is ignored. It is used to annotate console I, 
command sequences. 


3.6.6 Console Errors And Error Messages - 

The console can issue error messages in response to commands. Thes 
error messages are listed in table 5. 

Table 5: Console Error Messages 
Code Message Description 


?15 CORRPTN 


?16 ILL REF 


?17 ILL CMD 

?18 INV DGT 


The console program database has been 
corrupted, the console program does a powerup 
initialization to rebuild its database. 

The requested reference would violate virtual 
memory protection, the address is not mapped, 
the reference is invalid in the specified 
address space, or the value is invalid in the 

specified destination. 

The command string cannot be parsed. 

A number has an invalid digit. 
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Code Message Description 


?19 

LTL 

The command was too large for the console zc 
buffer. The message is issued only after 
receipt of the terminating carriage return. 

?1A 

ILL ADR 

The address specified falls outside the limizs 

of the address space. 

?1B 

VAL TOO LRG 

The value specified does not fit in the 

destination. 

?1C 

SW CONF 

For example, two different data sizes are 

specified with an EXAMINE command. 

? ID 

UNK SW 

The switch is unrecognized. 

?1E 

UNK SYM 

The symbolic address in an EXAMINE or DEPOSIT 
is unrecognized. 

?1F 

CHKSM 

The command or data checksum of an X command is 
incorrect. If the data checksum is incorrect, 
this message is issued, and is not abbreviated 
to "Illegal command". 

?20 

HLTED 

The operator entered a HALT command. 

?21 

FND ERR 

A FIND command failed either to find the RPB or 
64 kb of good memory. 

?22 

TMOUT 

During an X command, data failed to arrive in 
the time expected. 

?23 

MEM ERR 

Parity error detected. 


Some console commands may result in errors. For example, if a merr.o 
error occurs as the result of a console command, the console wi 
respond with an error message. 


3.6.7 Halts And Halt Messages - 

Whenever the processor halts, the console prints the response "PC 
<PC>". For example: 

?06 HLT INST 

PC = 800050D3 


36 




Digital Equipment Corporation - Software Specificari 

SOFTWARE CAPABILITY 


The number preceding the halt message is the halt code, and is passed 
the operating system on a restart. The halt messages are shown in tab 
6 . 


Table 6: KA630 Halt Messages 

Code Message Description 


?02 EXT HLT BREAK was typed on the console, QBINIT or 

QBHALT was asserted. 

?04 ISP ERR In attempting to push state onto the interrupt 

stack during an interrupt or exception, the 
processor discovered that the interrupt stack 

was mapped NO ACCESS or NOT VALID. 

?05 DBL ERR The processor attempted to report a machine 

check to the operating system, and a second 
machine check occurred. 

?06 HLT INST The processor executed a HALT instruction in 

kernel mode. 

?07 SCB ERR3 The vector had bits <1:0> equal to 3. 

?08 SCB ERR2 The vector had bits <1:0> equal to 2. 

?0A CHM FR ISTK A change mode instruction was executed when 

PSL<IS> was set. 

?0B CHM TO ISTK The exception vector for a change mode had bit 

<0> set. 

?0C SCB RD ERR A hard memory error occurred while the 

processor was trying to read an exception or 
interrupt vector. 

?10 MCHK AV An access violation or an invalid translation 

occured during machine check exception 

processing. 

?11 KSP AV An access violation or an invalid translation 

occured during processing of of an invalid 
kernel stack pointer exception. 


3.7 Program I/O Mode {System Running) 

When the processor is not executing instructions from the conso 
program ROM, it is in "program I/O mode" in which all termin 
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interaction is handled by the operating system. In program I/O mode 
the console terminal behaves like any other operating system terminal 
If halts are disabled, BREAK is ignored. If halts are enabled, BRE1 
causes the processor to "halt", that is the KA630 enters console I, 
mode. 


4 PUBLICATIONS 
tbd 


5 PACKAGING 

NOT APPLICABLE - This product resides in ROM and is shipped as part c 
the processor board. 

6 INSTALLABILITY 

NOT APPLICABLE - This product resides in ROM and is shipped as part c 
the processor board. 


7 EASE OF USE 

The users of the KA630 console program include many who ar 
sophisticated in their use and understanding of computers. These user 
are Engineering, Manufacturing and Field Service personnel as well a 
many customers. These users are not intimidated by the console comman 
language and its messages nor by the messages generated by the consol 
diagnostics. The relative complexity of these components of the consol 
system are perceived as worth the diagnostic power that they provide 
It is for these users that these features are provided. Indeed thes 
features have evolved over time to satisfy these users and therefore 
for this user group, the KA630 console program is regarded as "easy t 
use". 

Another class of users however are those users who know little abou 
computers and who may be intimidated by them. These users would like t 
simply flip a switch and know that the computer will turn on and the 
can proceed with their work. These users are not expected to use th 
console command language, nor are they expected to understand an 
diagnostic messages. 

If a KA630 is to be used by a user from the latter group, halts must b 
disabled, the appropriate bootstrap device configured, and the prope 
baud rate must be set. Establishing this configuration for th 
unsophisticated user may be done in manufacturing (the preferre 
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approach), by Field Service personnel, by a sophisticated user, or by a 
unsophisticated user following a well designed and document 
installation procedure. 

Once properly configured, assuming no hardware problems are detected z 
the diagnostics on power up, figure 9 shows what the user will sa 
displayed. 


Figure 9: Console Display on Successful Power-Up 


KA630.xx 

Performing normal system tests. 

7.. 6..5. .4..3.. 

Tests completed. 

Loading system software. 

2 .. 1 . .0 

<Operating system specific output> 


The first line identifies the processor and the version number (xx) c 
the console program ROM. The next line explains that the system i 
performing NORMAL tests. The count-down sequence reassures the use 
that the system is progressing through its tests, that the system hasn' 
"gone away", and documents which tests are executed. When diagnostic 
are completed, the console notifies the user that the diagnostic 
sucessfully completed. The "Loading system software." message indicate 
the beginning of the bootstrap sequence. The execution of the bootstra 
sequence causes the remaining digits of the countdown to be displayed 
Because successful completion of a bootstrap occurs in the context c 
the operating system bootstrapped, a confirming message indicating the 
the system startup has completed can only be issued by the bootstrappe 
operating system. 

Figure 10 shows the display generated if any hard errors are detecte 
during any test (test 7 for example). 


39 


rn n 




Digital Equipment Corporation - Software Specification 
EASE OF USE 


Figure 10: Console Display on Power-Up with Hard Errors 


KA630.xx 

Performing normal system tests. 
7 . . 

?<subtest> <pl> <p2> <p3> 
Failure. 

Normal operation not possible. 


In the case of fatal problems detected by the diagnostics, the coun¬ 
sequence is interrupted and a diagnostic message is displayed, 
diagnostic message is composed of a question mark, a subtest code nu 
and up to three parameters for use by diagnostic personel. More 
one such error message is possible but unlikely. The summary mes 

which follows indicates that the test failed and that normal opera 
is not possible. The console program then hangs. 


8 PERFORMANCE 

All diagnostic checks will be performed in less than tbd . Diagnc 
coverage of the processor itself will be tbd percent, coverage of 
memory system will be tbd percent, and coverage of the Q22-bus map 
be tbd . ~~ 

The console responds to all commands within 1 second. 

When the console power-up display is displayed, no more than 5 sec 
shall pass without some output to the screen (additional periods ma 
displayed during the countdown if necessary). 


9 RELIABILITY 

Errors detected by this program are classified as user errors, 
errors, or catastrophic errors. User errors are errors arising 
invalid input from the user. All user errors are diagnosed and the 
is notified by a diagnostic message on the console terminal. All 
errors are recoverable. 

Hard errors are errors detected by the program which w 
unrecoverable, do not prevent the continuation of the program, 
example of a hard error is the detection of an unexpected non-exis 
memory error when in console I/O mode. The console program notifies 
user of all hard errors with a diagnostic message on the console. 
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Catastrophic errors are errors of such a severe magnitude that th 
program cannot continue, When a catastrophic error is detected, rh 
program attempts to display an error message on the console terminal 
Following that, the processor goes into a infinite loop at IPL 31 (ther 
is no halt state for MicroVAX). An example of a catastrophic error i 
when the console program is unable to locate any working memory. 

It is possible to bypass all diagnostic tasks. This may done b 
enabling halts and by manually halting the processor following power- - ; 
or reset. The diagnostics will be halted and the processor will erne 
console I/O mode. This option allows a field service engineer to by?as 
a failing test and enter console I/O mode where the console commands cs 
be used to further diagnose the problem. 

As part of each diagnostic subtest, a test code is displayed on 
console and on the LEDs, making it possible to monitor the progres 
the diagnostics. The two display mechanisms use unrelated lo 
providing a high probability that at least one will be operative, 
hard error is detected by a test, a diagnostic message is displayed 
the console. If a catastrophic error occurs, it may not be possibl 
display a diagnostic message on the console but the most recent 
code will be left in the LEDs. 


10 MAINTAINABILITY 

The console program is located in two socketed ROM's on the K 
processor. If necessary, they can be replaced. This is the only 
of maintenance possible. 

The console program displays the version number of the console pro 
ROM when the power up messages are displayed. This can be use 
easily determine which version of the console program is present. 


Upon completion of development, the source co| 
will be preserved for ECO purposes by the VMS 


of the console 


11 MAINTENANCE 

The console program is located in two socketed ROM's on the 
processor. If necessary, they can be replaced. This is the only 
of maintenance possible. 


12 COMPATIBILITY 
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12.1 Product Compatibility 

This program is a new product developed for the first time for tha 
KA630. Even though other MicroVAX based processors might be able t 
utilize parts of this product, no effort is planned to facilitate sue 
sharing beyond that which arises naturally from sound modular design. 


12.2 Standards Conformance 

Although not required, the command language accepted by the console i 
intended to be as compatible as possible with that defined in II 
Standard 32. However, the following significant console features ar 
defined in the standard but omitted by the KA630 console program: 

o MICROSTEP command - not supported by the MicroVAX chip. 

o LOAD command - no console storage device is supported. 

o SET command - no set options are defined. 

o NEXT command - not supported by the MicroVAX chip. 

o @ command - no console storage device is supported. 


The console program recognizes terminal device attributes based c 
device attribute responses registered in DEC Standard 138. 

Escape sequence parsing (used to identify terminals and to cause al 
escape sequences to act as line terminators) is based on the algorithm 
defined in the "Video System Standards Reference Manual". 


12.3 Internationalization 

All console program message texts are either multilingual or langua 
independent. The message texts displayed on power-up (shown in figur 
9 and 10) are multilingual. All other texts are language independent: 
they incorporate short language insensitive abreviations rather tha 
readable sentences. Depending on the user preference, the message text: 
are output in either English, French, German, Italian, Portuguese 
Spanish, Dutch, Danish, Finnish, Norwegian or Swedish. 

Numeric status displays on the processor LEDs facilitate the diagnosi 
of failing processors in a language independent manner. 

The operation of the console is independent of the user's line vcltag 
or frequency. 
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Digital Equipment Corporation - Software Specificauic 

COMPATIBILi: 


The console supports the Digital Multinational Character Set (MCS' 
This support extends to displaying foreign language messages with >!C£ 
accepting and echoing MCS characters and accepting a device attrifcur^ 
report (the console queries the terminal to determine if it is a CRT : 
not) using the Cl control characters of MCS. However, all consol 
commands must be entered using the ANSI subset. 

If the terminal does not support MCS, the console uses English messa: 
texts. 

The console program uses four characters that are national replacemer. 
characters, the caret ( A ), the backslash (\) and the right and lei 
square brackets ([,]). The caret is used by the console to dencr 
control characters. The backslash is used to delimit text deleticr. 
when editing console input. The square brackets are used to aencc 
directory specifications when the user directs the bootstrap to solid 
a secondary bootstrap file name. No provision is made for terminal 
which replace any of these characters. 


13 EVOLVABILITY 

Because the console program is in ROM and cannot be easily changed, 
there is little likelihood of significant evolution over its lifetime 
An exception is support for additional bootstrap devices. 

Support for new types of disk and tape units is provided not by 
console program itself but by the console's support for MSCP and TM 
disks and tapes. Any new disk or tape supported by the MSCP and TM 
controllers will be supported by the console program. 

Another possible need is support for a new Ethernet controller. Any ne 
controller compatible with the old will be supported. Any new ar. 
incompatible controller could not be supported except by an ECO of ch 
console ROM. 

The console terminal recognition code relies on compliance with DE 
video terminal architecture standards to insure proper recognition o 
future terminals. 


14 COSTS 
NOT APPLICABLE 


15 TIMELINESS 

This product must be available for the first release of the KA63 
processor which is gated by availability of this product. 
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TIMELINESS 


In order to insure that this goal is met, every effort will be made 
minimize the interdependence of the KA630 development project 
others. For this reason, the KA630 development group will main- 
complete responsibility for the entry/dispatch code and the diagncs 
code. These sections are very processor implementation specific and 
done outside the group, schedule risk would be raised. 

The command language interpreter is less implementation specific 
because it will be needed early in the development phase of the KA6 
it will be done within the development group as well. 

The restart code will be done by the KA630 development group as well 
the bootstrap code will be written by the VMS development group. I 
the VMS supplied code will be available on schedule is insured by 
fact that the code is essentially the same as that in SEAHORSE, wh 
will be completed previously. 


16 CONSTRAINTS AND TRADEOFFS 

The following list reflects the priority ordering of the goals for t 
product (1 is highest): 

1. Time to market - must be available for the KA630 first relea 

2. Reliability - cost of field repairs is high, therefore, 
errors should ship. 

3. Bootstraps supported - must support RQDX1 disks and DE 
(DECNET). 

4. Diagnostic coverage - within available ROM space, diagnos 
coverage should be maximized. 

5. Memory consumption - ROM is available in 16, 32 and 64 

amounts. The console program should attempt to meet its gc 
within 32 Kb. 

6 . Support of QxSS based bitmapped terminals. 

7. Console I/O language complexity - reduction of comir. 
verbosity and editing capabilities will be considered to m 
space and schedule goals. 


If necessary, to meet the highest priority goals lower priority gc 
will be compromised. 
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APPENDIX A 


INTERPRETATION OF KA630 LED AND CONSOLE DISPLAY CODES 


There are four red LEDs on the KA630 (echoed off the processor board 
well). These four LEDs, interpreted as a four bit hexadecimal di 
have the meanings described in table A-l . All LED codes are displ 
during power-up. A problem is indicated only if the LED code 
continuously displayed. 

Each LED is illuminated if its control bit in the boot and diagnose 
register (BDR) is one and is dark if its control bit is zero. 

It is possible for privileged code to output to the LEDs when t 
processor is in program mode. Because this may cause confusion in e 
interpretation of the LEDs, this use of the LEDs in program mode 
discouraged. 

When executing the power-up sequence, the codes '9' through 'O' are al 
output to the console terminal. See figures 9 and 10. 


Table A-l: KA630 LED Interpretation 

Code Activity Exit Criteria 


F Electrical power-up. 


E Wait for PWR-OK. 

D Perform ROM checksum and TOY 

RAM tests. (1) 

C Initialize console program 

memory. 

B Run IPCR tests. (1) 

A Test for and check out QxSS 

video console display if 
present. (1) 


MicroVAX starts execution from 
console program ROM. 

BDR<15> set. 

Test success. 

Console memory and bitmap ini¬ 
tialized, registers saved. 

Test success. 

QxSS operational or not 
present. 
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INTERPRETATION OF KA630 LED AND CONSOLE DISPLAY CODES 


Table A-l (cont.) 

Code Activity Exit Criteria 


9 

8 

7 

6 

5 

4 

3 

2 

1 

0 


Perform console port tests and 
terminal identification. (1) 

Query console language (1) , 
then enter console command 

mode. 

Run memory pattern tests. (2) 

Run memory address tests. (1) 

Run I/O map tests. (1) 

Run CPU tests. (1) 

Run Interrupt tests. (1) 

Search for bootstrap device. 
(3) 

Load bootstrap. (3) 

Program mode. 


Console terminal type 

determined. 

Exits automatically cr. 

power-up, otherwise exits cr. 
console CONTINUE, START, BOCC 

or TEST command. 

At least 64 kb of contiguous 

good memory found. 

All address tests passed. 

Test success. 

Test success. 

Test success. 

Valid bootstrap device locac- 
ed. 

Bootstrap successfully loaded. 
Not applicable. 


(1) Performed only on power-up entry into console program. 

(2) Performed on power-up entry and on operator requested 
bootstrap. 

(3) Performed only during bootstrap. 
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APPENDIX B 


SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRAM 


B.l BOOT AND DIAGNOSTIC CONFIGURATION REGISTER (BDR) 

The BDR register is used to read the values of the KA630 configurari; 
switches and to output to the processor LED display. 


15 14 13 12 11 10 9 8 7 

|PWR|HLT| | CPU | BDG | 

| OK |ENB| | | ! 


6 5 4 3 2 1 0 


DSPL 


+ 


Boot and Diagnostic Register 
Hex addr: 20080000 (hex) 


BDR<15> PWR OK Power OK - set when power is stable. 

BDR<14> HLT ENB Halt enable - A read only bit that enable 

recognition of the BHALT(L) bus signal as a hal 
condition and enables recognition of a BREA 
condition from the console terminal as a hal 
condition. If not set, neither condition wil 
result in a processor halt. This bit is set t 
a switch external to the KA630. 

If CPMBX<1:0> is zero, this bit also control 
the actions of the console program in respons 
to any halt condition. If set the consol 
program will enter console I/O mode followir. 
any halt. If not set the console program wil 
attempt to restart the processor and if tha 
fails, it will attempt to reboot the processor 
If that fails as well, the console program wil 
then enter console I/O mode. If CPMBX<1:0> i 
non-zero, the console program uses that field t 
determine its actions on processor halt. 
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SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRAM 
BOOT AND DIAGNOSTIC CONFIGURATION REGISTER (BDR) 


BDR<12:11> CPU CPU designation 

0 Arbiter CPU 

1 Auxiliary CPU number 1 

2 Auxiliary CPU number 2 

3 Auxiliary CPU number 3 

BDR<10:9> MODE Power-up mode control bits. These two bits a: 

combined with the HLT ENB to generate a thra 
bit power-up mode field. The interpretation 
this three bit field is given in table 1. 

BDR<3:0> DSPL LED display bits - these write-only bits 

used to load the LED status display. A. 
value of one causes the associated LED to 
illuminated, a bit value of zero causes the LZ 
to be dark. 


B .2 TIME OF YEAR (TOY) CLOCK REGISTERS 

The TOY registers contain the time of year clock registers as well as 5 
bytes of battery backed-up RAM. The console program references ch 
clock registers only to check for battery backup failure. See th 
KA630-A Processor Specification for information on the TOY clcc 
registers. The console program reserves all of the RAM registers 
There are a total of 64 eight bit registers, word aligned. They may h 
accessed either as bytes or as words. When accessed as words, bir 
<15:8> are ignored on writes and return zeros on reads. The bas 
address of the TOY registers is 200B8000 (hex). 


B.2.1 Console Program Mailbox (CPMBX) 

The console program and the operating system communicate with each othe 
via this register. 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

—-— — —-- - - - - - — — -- - --L — | — — — —. — — 

| | LNG |RIP|BIP| HLT | 

I I III ACT | 

-f — — — — — — — — — — — — — — — — — — — — — — _ _ _ _— -J_ — |_—_ 

Console Program Mailbox Register (CPMBX) 


TOY register 14, Hex addr: 200B801C 


CPMBX<7:4> LNG Console Message Text Language. This fiel 
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SUMMARY OF I/O REGISTERS USED BY CONSOLE PRC SR.- 
TIME OF YEAR (TOY) CLOCK REGISTER 


controls the output of message texts to t; 
console terminal. If the field is set to zer: 
the console program will prompt the user to 
this field on power up. 


0 Prompt for language. 


1 German 

2 English 

3 Spanish 

4 French 

5 Italian 


6 Danish 

7 Dutch 

8 Finnish 

9 Norwegian 
10 Swedish 


11 Portuguese 


CPMBX<3> RIP If set, a restart attempt is in progress. Thi 

flag must be cleared by the operating system i 

the restart succeeds. 

CPMBX<2> BIP If set, a bootstrap attempt is in progress 

This flag must be cleared by the operatir. 

system if the bootstrap succeeds. 

CPMBX<1:0> HLT ACT Processor halt action - this field is used t 

control the automatic restart/bootstra 
procedure. This mailbox allows operating sysre 
software to override the BDR HLT ENB field 
Both bits are cleared on power up and when th 
console program exits. 

0 Use HLT ENB (BDR<14>) to determir. 

action. 

1 Restart, if that fails, halt. 

2 Reboot, if that fails, halt. 

3 Halt. 


B.3 SYSTEM IDENTIFICATION EXTENSION REGISTER (SIDEX) 

Any MicroVAX based system must implement a longword at physical locatic 
20040004 (hex) to distinguish it from other MicroVAX based system. Th 
MicroVAX implements the system identification IPR but this register oni 
identifies the processor implementation, not the system itself. Thi 
longword exists in the physical address range of the KA630-A consol 
program ROM. 
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SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRAM 
SYSTEM IDENTIFICATION EXTENSION REGISTER (SIDEX) 


3 2 2 1 1 

1 4 3 6 5 0 

+-+-+- 

| SYSCODE | VERSION | reserved 

+-+-+- 

System Identification Extension (SIDEX) 


SIDEX<31:24> SYSCODE System code. This field is 1 for the KA630-A. 

SIDEX<23:16> VERSION Version number of console program ROM. 

SIDEX<15:0> Reserved. 


B.4 CONSOLE TERMINAL REGISTERS 

The console program accesses the console terminal through four interna 
processor registers, the Console Receive Control and Status Regises 
(RXCS) , the Console Receive Data Buffer Register (RXDB), the Consol 
Transmit Control and Status Register (TXCS), and the Console Transmi 
Data Buffer Register (TXDB). See the KA630-A Processor Specificatic 
for their definition. 


B.5 INTERPROCESSOR COMMUNICATION REGISTER (IPCR) 

The IPCR register is used to support communication between arbiter an 
auxiliary processors. It controls the visibility of auxiliary memory c 
the Q-22 bus, it allows an auxiliary processor to be halted by anothe 
processor, and it provides for an interprocessor interrupt capability 
The location of the IPCR in the Q-22 bus address range depends on th 
CPU identification code of the processor. 
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SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRJ 
INTERPROCESSOR COMMUNICATION REGISTER (IPCZ 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

+-+-+-+-+-+-+-+-+ 

|DMA| |AUX| |IE |LM | I IRQ I 

|QPE| [HLT| | |EAE| I | 

+-+-+-4--+-+-+-+-+ 


Interprocessor Communication Register 


Hex address: 

20001F40 

Arbiter 



20001F42 

Auxiliary 

#1 


20001F44 

Auxiliary 

#2 


20001F4 6 

Auxiliary 

#3 


ICR<15> 


ICR<8> 


ICR<6> 


ICR<5> 


ICR<0> 


DMA QPE DMA Q-22 address space parity error. This rea 
only bit is set whenever a parity error i 

detected when an external CPU or devic 

references KA630 local memory. (Not used by th 
console program). 

AUX HLT Auxiliary halt. A read/write bit which when se 
on an auxiliary processor, it causes th 
processor to halt. This bit has no effect i 

the auxiliary is in console I/O mode and i 

ignored all together by arbiter processors 
This bit is always cleared upon entry int 
console I/O mode. It is also used by auxiliar 
processors as part of its bootstrap process (se 
section 3.5.1.7) . 


IE 


LM EAE 


IRQ 


Interrupt enable. If set, an interrupt will t 
generated if IPCR<0> is set. To the loca 
processor this is a read/write bit. To externa 
processors this is a read only bit. 

Local memory external access enable. When thi 
bit is set, local memory can be accessed via th- 
Q-22 bus map. To the local processor this is 
read/write bit. To external processors this i 

a read only bit. 

Interrupt request. When set, a processo 
interrupt is requested. This bit is enabled b; 
ICR<6>. If ICR<6> is not set, writes to thi. 
bit are ignored and the bit is not set. 
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APPENDIX C 


QXSS AND APT 


When a KA630 system powers up for the first time it determines wha 
console device is present. If the console device is a QxSS vita 
display, it uses it as the console. However, during manufacturir.c 
systems are tested by APT which relies on the console program using th 
console port rather than the QxSS. 

To continue to support APT testing, the KA630 console program allows A? 
to force the console program to revert to using the console port insts= 
of the QxSS. To do this, APT must wait until the system has complete 
its power-up. APT then asserts break and the system halts. When ti 
console program halts, it checks for the existance of a break conditic 
on the console port. If break is being asserted, the console procra 
resets itself to assume that the console port is connected to a hardccr 
terminal and the console language is English. APT can now use ti 
system normally. 

Once this is done, there is no way short of powering the system off ar. 
turning it back on again to cause the console program to resume use c 
the QxSS as the console display device. 
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APPENDIX D 


OUTSTANDING ISSUES 


1. Section 1, page 1 - QVSS support needs to be further define 
within this specification. The intent to support is define 
but the exact definition of that support is TBS. This i 
important as QVSS is considerably more complicated to supper 
than a console terminal. 

2. Section 3.5.1.1, page 16 - More details on MAYA and QI 

descriptions are needed, planned controller names, uni 
designations, etc. 

3. Section 4, page 38 - What should be in the publication 

section? 

4. Section 8, page 40 - Need performance indications fre 

diagnostics. 

5. Section 10, page 41 - Need agreement from VMS that they wil 
take the console program sources as part of VMS source kit. 


[End of file] 
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